System, method, and device for playing back recorded audio, video or other content from non-volatile memory cards, compact disks, or other media

ABSTRACT

A secure software package for original equipment manufacturers to run in electronic devices in order to access and dynamically decrypt encrypted audio video or other content from a memory storage device such as a memory card, optical or hard disk such that the user interface of the device need only send simple commands and the decrypted content is output.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/006,554 filed Dec. 6, 2001 to Farshid Sabet-Sharghi et al., entitled“System, Method, and Device for Playing Back Recorded Audio, Video orOther Content From Non-Volatile Memory Cards, Compact Disks, or OtherMedia”, which claims the benefit of U.S. Provisional Patent ApplicationSer. No. 60/251,731 filed Dec. 7, 2000 to Farshid Sabet-Sharghi et al.,entitled “Secure Software System for Playing Back Recorded Audio, Videoor Other Content From Non-Volatile Memory Cards, Compact Disks or OtherMedia”.

This application is related to U.S. Pat. No. 7,227,952, issued on Jun.5, 2007 to Bahman Qawami et al. entitled “System, Method, and Device forPlaying Back Recorded Audio, Video or Other Content From Non-VolatileMemory Cards, Compact Disks or Other Media” and application Ser. No.11/809,222 filed May 31, 2007 to Bahman Qawami et al., entitled “System,Method, and Device for Playing Back Recorded Audio, Video or OtherContent From Non-Volatile Memory Cards, Compact Disks or Other Media”.

These applications are hereby incorporated by this reference in theirentirety.

Source code is submitted on a compact disc according to 37 CFR 1.52 asan appendix containing the following files, each of which is herebyincorporated by this reference in its entirety:Sd_security\Sd_oem\Makefile, Nov. 05, 2001, 2KB;Sd_security\Sd_oem\Readme, Nov. 05, 2001, 3KB;Sd_security\Sd_oem\Sd_oem.c, Nov. 05, 2001, 6KB;Sd_security\Sd_oem\Sd_oem.h, Nov. 05, 2001, 1KB;Sd_security\Sd_oem\Sd_oem.inc, Nov. 05, 2001, 1KB;Sd_security\Sd_oem\Sdtypes.h, Nov. 05, 2001, 3KB;Sd_security\Sd_oem\vssver.scc, Nov. 05, 2001, 1KB;Sd_security\Security\Tstsampl\Dotest.c, Nov. 05, 2001, 8KB;Sd_security\Security\Tstsampl\Makefile, Nov. 05, 2001, 4KB;Sd_security\Security\Tstsampl\Readme, Nov. 05, 2001, 3KB;Sd_security\Security\Tstsampl\Regress.c, Nov. 05, 2001, 26 KB;Sd_security\Security\Tstsampl\Sdls.c, Nov. 05, 2001, 10KB;Sd_security\Security\Tstsampl\Sdrm.c, Nov. 05, 2001, 5KB;Sd_security\Security\Tstsampl\Securmmc.c, Nov. 05, 2001, 6KB;Sd_security\Security\Tstsampl\Tstsampl.inc, Nov. 05, 2001, 1KB;Sd_security\Security\Tstsampl\vssver.scc, Nov. 05, 2001, 1KB;Sd_security\Security\Err.h, Nov. 05, 2001, 1KB;Sd_security\Security\Fsentry.c, Nov. 05, 2001, 7KB;Sd_security\Security\keyInfo.h, Nov. 05, 2001, 84KB;Sd_security\Security\Makefile, Nov. 05, 2001, 3KB;Sd_security\Security\Readme, Nov. 05, 2001, 4KB;Sd_security\Security\Scdrv.c, Nov. 05, 2001, 29 KB;Sd_security\Security\Scdrv.h, Nov. 05, 2001, 5KB;Sd_security\Security\Scfs.c, Nov. 05, 2001, 13KB;Sd_security\Security\Scfs.h, Nov. 05, 2001, 4KB;Sd_security\Security\Sdsec.h, Nov. 05, 2001, 5KB;Sd_security\Security\Sdsys.c, Nov. 05, 2001, 2KB;Sd_security\Security\Security.c, Nov. 05, 2001, 64KB;Sd_security\Security\Smanager.c, Nov. 05, 2001, 7KB;Sd_security\Security\Smanager.h, Nov. 05, 2001, 2KB;Sd_security\Security\Ssmapi.c, Nov. 05, 2001, 3KB;Sd_security\Security\vssver.scc, Nov. 05, 2001, 1KB;Sdaudlib\HostFunc.c, Nov. 05, 2001, 3KB; Sdaudlib\Inpoutp.c, Nov. 05,2001, 1KB; Sdaudlib\mssccprj.scc, Nov. 05, 2001, 1KB;Sdaudlib\plmInfo.h, Nov. 05, 2001, 16KB; Sdaudlib\Sd_plm.h, Nov. 05,2001, 5KB; Sdaudlib\Sd_tkm.h, Nov. 05, 2001, 4KB; Sdaudlib\Sd_types.h,Nov. 05, 2001, 2KB; Sdaudlib\Sdapi.h, Nov. 05, 2001, 2KB;Sdaudlib\Sdaudapi.c, Nov. 05, 2001, 91KB; Sdaudlib\Sdaudapi.h, Nov. 05,2001, 8KB; Sdaudlib\Sdaudlib.dsp, Nov. 05, 2001, 4KB;Sdaudlib\Sdaudlib.dsw, Nov. 05, 2001, 1KB; Sdaudlib\vssver.scc, Nov. 05,2001, 1KB.

BACKGROUND

1. Field of the Invention

This invention relates generally and specifically to secure playback ofdigital audio, video or other content from memory cards, compacts disksor other media.

2. Related Art

The potential of electronic distribution of copyrighted music over theInternet, by other communication systems or through retail kiosks, isbeing limited by concerns about unauthorized copying of the music. Thisis also the case for other audio, as well as video, content. The contentis typically provided to the ultimate customer in encrypted form, andthe customer records the encrypted content files onto some storagemedia, such as a personal computer memory, a memory of a portableplaying device, a writable compact disk (CD) or a non-volatile memorycard. Providers of the content would like to eliminate the possibilityof unauthorized copying of the content but have to be satisfied withtaking steps that minimize the amount of copying that occurs. Thisincludes providing protection of the content on the recording media. Theprotection of content stored on non-volatile memory cards is describedherein, as specific examples, but the same content protection techniquescan be applied to compact disks or other recordable media.

There are several commercially available non-volatile memory cards thatare suitable for use as the content data storage media. One is theCompactFlash (CF) card, another is the MultiMediaCard (MMC), and yetanother is the Secure Digital (SD) memory card that is closely relatedto the MMC card. All three, and others, are available in various storagecapacities from SanDisk Corporation of Milpitas, Calif., assignee of thepresent application. The physical and electrical specifications for theMMC are given in “The MultiMediaCard System Specification” that isupdated and published from time-to-time by the MultiMediaCardAssociation (“MMCA”) of Cupertino, Calif. Versions 2.11 and 2.2 of thatSpecification, dated June 1999 and January 2000, respectively, areexpressly incorporated herein by this reference. The MMC products arealso described in a “MultiMediaCard Product Manual,” Revision 2, datedApril 2000, published by SanDisk corporation, which Manual is expresslyincorporated herein by this reference. Certain aspects of the electricaloperation of the MMC products are also described in patent applicationsof Thomas N. Toombs and Micky Holtzman, Ser. No. 09/185,649, now U.S.Pat. Nos. 6,279,114, and 09/186,064, now U.S. Pat. No. 6,901,457, bothfiled Nov. 4, 1998, and assigned to SanDisk Corporation. The physicalcard structure and a method of manufacturing it are described in U.S.Pat. No. 6,040,622, assigned to SanDisk Corporation. These patents arealso expressly incorporated herein by this reference.

The newer SD Card is similar to the MMC card, having the same in planview. A primary difference between them is that the SD Card includesadditional data contacts in order to enable faster data transfer betweenthe card and a host. The other contacts of the SD Card are the same asthose of the MMC card in order that sockets designed to accept the SDCard will also accept the MMC card. The electrical interface with the SDcard is further made to be, for the most part, backward compatible withthe MMC product described in version 2.11 of its specificationreferenced above, in order that few changes to the operation of the hostneed be made in order to accommodate both types of card. The electricalinterface of the SD Card, and its operation, are described in co-pendingpatent application Ser. No. 09/641,023, filed Aug. 17, 2000, now U.S.Pat. No. 6,820,148, which application is incorporated herein in itsentirety by this reference.

SUMMARY OF THE INVENTION

Encrypted content is difficult to access, and memory cards or compactdisks with encrypted content each have specific structures that requirespecific commands and routines to access encrypted and unencryptedcontent. The software of the present invention is a simple solution thatany original equipment manufacturer (OEM) can install and run on amyriad of different types of devices having a myriad of different typesof microprocessors. These devices range from personal computers toportable devices to car stereos, and include any device from which onewould like to access content that may be encrypted. The portable devicesmay be portable audio players or cell phones or portable organizers orgenerally any microprocessor controlled portable device. The storagemedia may be flash memory or any type of recordable disk. The devicesmay have a simple or powerful microprocessor with a small or largeamount of memory. The software utilizes and requires only a small bufferfor encryption purposes and is designed to run efficiently even inenvironments with limited processing power and memory. It can be run byany type of general purpose microprocessor, or special purposemicroprocessors such as a DSP, or an ASIC. Additionally, computationallydemanding portions of the software, such as the encryption anddecryption (security) engine may be executed by the DSP, while otherportions of the software may be executed by another microprocessor or anASIC.

The software has audio, video and image interfaces to receive commandsfor each of the respective types of files. These interfaces can organizeplayback and recording, including managing playlists and otherconvenient features. Thus, whatever the device, it need only issue acommand to an interface and the software will take care of reading orwriting data from the secure media, and decoding and decompressing thedata from any well known audio, video or image file formats within theaudio video or image engines.

The encryption and decryption takes place in an isolated module that isvery difficult to access and thus isolated from any attempts fromunauthorized persons wishing to access encryption keys in order to copythe files from the media or the device. Content is only decrypted insmall portions, and a method of dynamic key generation and deletionminimizes exposure of decrypted keys.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an illustration of the devices used to read and writeinformation on a secure media.

FIG. 2 is a schematic diagram of a device used to access the securemedia.

FIG. 3A is an abstract illustration of the layers of the secure media.

FIG. 3B is an illustration of the physical and logical structure of thememory cells of the secure media.

FIG. 3C is an illustration of the track structure and the componentparts of a track.

FIG. 4 is an illustration of a media key block (MKB) image broken intoits component chunks.

FIG. 5 is an illustration of a portion of the authentication anddecryption process.

FIG. 6 is an illustration of the authentication and encryption process.

FIG. 7 is a schematic of the authentication key exchange process shownin FIG. 6.

FIG. 8A is a block diagram of the software of the present invention.

FIG. 8B is a block diagram illustrating the modules of the software ofthe present invention.

FIG. 8C is a flow chart overview of the pre-play and play processaccording to the present invention, with the related API modules/callsshown.

FIG. 8D is an expanded flow chart of audio content initialization phasein FIG. 8C.

FIG. 8E is an illustration of information blocks created during thepre-play process 805 of FIG. 8C.

FIG. 9 is a flow chart overview of the playback of an audio trackaccording to the present invention.

FIG. 10 is a flow chart of the processing of an MKB image seen in FIG.4, a step of FIG. 9.

DETAILED DESCRIPTION OF THE INVENTION

Encrypted content is difficult to access, and memory cards or compactdisks with encrypted content each have specific structures that requirespecific commands and routines to access encrypted and unencryptedcontent. The software of the present invention is a simple solution thatany original equipment manufacturer (OEM) can install and run on amyriad of different types of devices having a myriad of different typesof microprocessors. These devices range from personal computers toportable devices to car stereos, and include any device from which onewould like to access content that may be encrypted. The portable devicesmay be portable audio players or cell phones or portable organizers orgenerally any microprocessor controlled portable device. The storagemedia may be flash memory or any type of recordable disk. The devicesmay have a simple or powerful microprocessor with a small or largeamount of memory. The software utilizes and requires only a small bufferfor encryption purposes and is designed to run efficiently even inenvironments with limited processing power and memory. It can be run byany type of general purpose microprocessor, special purposemicroprocessors such as a DSP, or an ASIC. Additionally, computationallydemanding portions of the software, such as the encryption anddecryption (security) engine may be executed by the DSP while otherportions of the software may be executed by another microprocessor or anASIC. The source code referred to in the Cross Reference section forms apart of this application, and is hereby expressly incorporated in itsentirety by this reference.

With reference to FIG. 1, an exemplary system is described in whichcontent protection is applied to audio content such as music. A hostcomputer device 11 may be a personal computer (PC), as shown, a kiosklocated in a retail store to distribute music or other content, or thelike. An SD memory card 13 is used in this example to store music. Thecard 13 is insertable into a utilization device, in this case a portabledevice (PD) 15 that operates from batteries to play the music or otheraudio content recorded on the card 13 through personal earphones. Themusic may be stored on the card 13 when inserted into the device 15 byconnecting the device 15 to the host 11, such as through a computeruniversal serial bus (USB) connection 17. Alternatively, if the playerdevice 15 is not provided with the capability of recording content ontothe card 13, or if it is otherwise desirable, a card writer/reader 19may be connected to the computer through a USB connection 21, and thecard 13 inserted into it for recording music on the card. The card 13 isthen removed from the writer/reader 19 and inserted into the portabledevice 15 to play the audio content recorded on the card. The host 11 istermed a licensed compliant module (LCM) when it includes the softwarenecessary to write to and read from the card 13 content data inaccordance with the security and authentication protocols of the 4CEntity and the SD Group.

The electronic system within the example portable utilization device 15is illustrated in FIG. 2. Operably connected together through a bus 23are a computing unit (MCU) 25, preferably with some non-volatile flashmemory 25A, system memory 27, which is preferably a high speed randomaccess memory (RAM), and interface circuits 29 for connecting with thememory card 13. The USB connection 17 is also optionally provided to theMCU 25. A digital signal processor (DSP) 31 is also included, whenneeded, for decompressing and/or decrypting content data, such as audioor video data, that is stored in a compressed and/or encrypted form. DSP31 also has its own RAM memory 31A included as part of the processor.DSP 31 may or may not be included. Furthermore, if a DSP processor isincluded, it may perform the functionality of MCU 25, and thus MCU 25may therefore be eliminated. Read only memory (ROM) 32 can store part orall of the software of the invention. Software instructions and data inROM 32 can be executed or read directly from ROM 32 or first shadowedinto any RAM memory included in the circuitry of the device.

Specifications for the protection of content on recordable media havebeen jointly established by Intel Corporation, International BusinessMachines Corporation, Matsushita Electric Industrial Co., Ltd. andToshiba Corporation (4C Entity). Particularly relevant here are thefollowing three publications of the 4C Entity, which are expresslyincorporated herein by this reference: “Content Protection forRecordable Media Specification, Introduction and Common CryptographicElements,” Revision 0.94, October, 2000, “Content Protection forRecordable Media Specification, SD Memory Card Book,” Revision 0.95,May, 2001, and “C2 Block Cipher Specification,” Revision 0.9, January,2000, and “Content Protection for Recordable MediaSpecification, DVDBook,” Revision 0.95, May, 2001. Additional detailed specifications forimplementing these 4C Entity specifications on SD memory cards have beenestablished by Matsushita Electric Industrial Co., Ltd. (MEI), SanDiskCorporation and Toshiba Corporation (SD Group).

Referring to FIG. 3A, a memory card 13 can be thought of as having fourdistinct layers. Such layers may also be present in other types ofsecure media.

At its most basic level, data is stored in memory cells arranged inclusters on the physical layer 13 d of memory card 13. The data isencrypted or secure if it is copyrighted material or otherwise worthy ofencryption. Keys used to encrypt and decrypt the secure content are alsoencrypted and stored in a secure area of the physical layer.

The software of the present invention runs within a device to allow thedevice to store and retrieve encrypted information without themanufacturer (OEM) having to program very specific instructions toaccess the memory cells containing encrypted data and keys. It containsmethods of sending the encrypted data to the device, decrypting the datawithin the device, and decompressing and playing audio, video and imagefiles upon requests from the device. In short, a device need only send acommand such as “play track.” The software will accept the command,retrieve the encrypted data stored in the memory cells, retrieve theencrypted keys, organize and decrypt the data, decompress and format it,and play the song back.

Logical layer 13 c contains the organizational structure for the memorycells and clusters of physical layer 13 d. The two layers 13 c and 13 dcontain and logically structure the memory of card 13. As card 13 is asecure card, security layer 13 b controls and limits access to thesecure data housed in the layers below.

Application layer 13 a is the part of memory card 13 that communicateswith a device accessing the content stored in the card. It does thisthrough a device interface or contacts 39. Memory card 13 preferablyincludes a controller that manages the operation of the card andfunctionality of the application layer 13 together with control of alllayers 13 a-d of the card.

The physical and logical structure of a recording media, the SD card 13,according to the foregoing specifications, and corresponding to layers13 c and 13 d of FIG. 3A, is illustrated in FIG. 3B. The card includesan array of memory cells 33 and a memory controller 35. User data,commands and status signals are communicated between the controller 35and the memory array 33 over a circuit 37. The controller 35communicates with a host device connected to a socket in which the cardis inserted through a series of electrical contacts 39 on the card.

The memory cells of the array 33 are divided into the fournon-overlapping areas of cells that are individually designated to storedifferent types of data. A largest storage capacity area 41 isdesignated to store user data, in this case, encrypted audio, video orother data. The user data may or may not also include unencrypted data.A system area 43 of the memory stores a 64-bit media identifier(IDmedia) of the card manufacturer, and 16 media key blocks (MKB)provided by the 4C Entity, each MKB having a maximum size of 4k bytes,all being pre-recorded by the card manufacturer. One of the 16 MKBs isspecified for use with audio user data, another for use with video userdata, another for use of image data, and so on. The system area 43 is awrite-protected area that is accessible for reading from outside of thecard. A hidden area 45 carries 16 pre-recorded media unique keys (Kmu)corresponding to the 16 distinct media key blocks (MKB) stored in thesystem area 43. The hidden area 45 is a write-protected area that isaccessible only by the memory card itself. A protected area 47 is aread/write area that is accessible only after a successful explicitmutual authentication has occurred. Randomly picked title keys (Kt) andcopy control information (CCI) are stored in the protected area 47 in anencrypted form. Each piece (file) of content stored in the user dataarea 41 is encrypted with a unique title key that is also stored in anencrypted form in the protected area 47. The title keys and CCI storedin the protected area 47 are concatenated and encrypted together by themedia unique key, which is unique for each memory card and stored in itshidden area 45.

The file system of the user data area 41 is typically an ordinary FATfile system. The FAT system describes what memory clusters make up whattracks and the various sub-components of the tracks. Audio or videotracks within user data area 41 may comprise multiple files asillustrated in FIG. 3C. Audio files are referred to as audio objects(AOB's) and picture files are referred to a picture objects (POB's). Atrack may comprise both. Track 300, for example is composed of AOB 304and AOB 308, and track 302 is composed of AOB 306 and the last track xxxis composed of AOB xxx and POB xxx. Each AOB or POB is also broken downinto sub components. AOB 304 is shown broken down into AOB blocks 312,which are further broken down into AOB elements 316 with header 318.Each element may be stored in one or more memory clusters of memory card13. AOB elements are divided into the lowest component level, AOB frames320. Depending on the encoding and compression of the content, each twoseconds may comprise a varying number of frames. A time search table(TMSRT) has information about the number of frames and data size whichcorresponds to “every two seconds” of playback. This information is usedwhen an audio or video track and the component AOB's elements and framesare accessed for fast forward and rewind. Also, as will be discussedlater with regard to FIGS. 9 and 10, at title key (Kt) is an a decryptedstate only for the time it takes to access this “every two seconds” ofcontent, although anywhere from less than one to ten seconds of contentmay be decrypted at a time. For further detail, please refer to the CPRMSpecification, SD Memory Card Book, which was previously incorporated byreference.

The media key block (MKB), as stored in the system area 43 of the cardmemory, contains a sequence of contiguous records, one such record beingillustrated in FIG. 4. The entire MKB image 49 is 64 Kbytes. It isbroken into 128 chunks of 512 bytes, and chunk 1, which contains all orpart of the first record, and is labeled MKB chunk 50 in the figure, isenlarged to show its component parts. Chunk 50 may also contain multiplerecords. A first field 51 contains the record type, a second field 53the total length of the record, and the remaining field 55 the keyitself. The data in the record type and length fields 51 and 53 are notencrypted. Each record of the MKB is a multiple of 4 bytes in totallength. As illustrated by a block 57 of FIG. 5, the MKB key records aredecrypted by device keys stored in the portable device (PD), licensedcompliant module (LCM) or other device that utilizes a memory card forreading or programming content data stored on it. Device keys Kd1, Kd2,Kd3 . . . are written into a memory of the utilization device, such asnon-volatile flash memory within the MCU 25 of the portable audio playerof FIG. 2, by the manufacturer of the device. The device keys areprovided to device manufacturers by the 4C Entity, and are maintained inconfidence. The number of device keys which are stored in a givenutilization device depends upon the type of the device.

The utilization device (PD, LCM or other device) which performs theprocessing of FIG. 5 calculates the media key Km as part of thedecryption of block 57, which is discussed in further detail with regardto FIGS. 9 and 10. Each record (FIG. 4) of the MKB read from the systemarea of an inserted memory card is usually processed in this manner.After processing of the MKB is completed, the most recently calculatedKm value is taken as the secret media key output of the block 57. Thismedia key Km and the media identifier IDmedia are combined by use of aC2 one-way function, as indicated by a block 59 of FIG. 5, to producethe media unique key Kmu. Additional details of this processing may behad by reference to the 4C Entity publications referenced previously.

FIG. 6 illustrates all of the authentication and encryption processingthat takes place when either recording audio content onto, or playingaudio content from, a memory card 13 having the memory space allocationof FIG. 3. Processing that takes place in a personal computer or otherLCM 63 is illustrated for recording audio or other content onto the card13. Similarly, the processing of a portable audio or other utilizationdevice 65 is shown for reading the recorded content from the card 13.Included in both is the processing described with respect to FIG. 5, theprocessing blocks 57 and 59 being part of the utilization device 65 andcorresponding processing blocks 57′ and 59′ being part of the contentrecording system 63.

As part of recording content, an arbitrarily assigned title key Kt isinput at a line 67 for use by an encryption module 69 to encrypt onefile (piece) of audio or other content input at line 71. The encryptedfile is then stored in the user data area 41 of the memory card 13. Inorder to make the title key available for decrypting the recordedcontent, an encrypted version of the title key (Kt) is stored in theprotected card memory area 47, as previously described. An encryptedversion of the title key (Kt) is also stored in either system memory 27,RAM memory 25A of MCU 25, or RAM memory 31A of DSP 31. Storing theencrypted title key (Kt) in a memory of the device eliminates the needto access protected card memory area 47. This is significant because itsaves considerable time and processing capacity in comparison toaccessing the protected area 47 for each read. This will be discussedlater with regard to FIG. 9. The title key Kt and copy controlinformation CCI are encrypted by a series of encryption modules 75, 77and 79 in the LCM 63, and a module 81 on the memory card 61. The mediaunique key Kmu is used by the module 77. An authentication key exchange(AKE) module 83 combines the media unique keys Kmu as calculated by themodule 59′ and stored in the hidden area 45 of the card 61, to generatea session key Ks that is used by each of the modules 79 and 81. In orderfor the utilization device 65 to decrypt the recorded encrypted content,corresponding modules, indicated with the same reference numbers butwith a prime (′) added, are utilized to perform an inverse of theencryption process.

FIG. 7 illustrates a technique for accessing the protected area 47 of amemory card, utilizing an authentication and key exchange (AKE)challenge-response protocol between a card and some LCM or utilizationdevice. When this authentication is successful, the card and the othermodule or device share a secure common session key Ks. Additionaldetails of the forgoing processing and protocols may be had by referenceto the 4C Entity publications previously identified.

FIGS. 8A and 8B illustrate an embodiment of a software system designedto run in a portable device or LCM in order to access informationencrypted with the aforementioned processes. The SanDisk software, SW100, is a complete turn-key software solution that enables OEM musicplayers and recorders to readily support secure media including thesecure digital (SD) memory card. SW 100 shown within portable device 15in order to access SD card 13. SW 100 may also be installed in anylicensed compliant module such as a personal computer. As seen in FIG.8A, at its highest level, SW100 receives calls from device 15,particularly a user interface of device 15, retrieves encrypted contentfrom the Secure Digital card 13, and returns decrypted content to thedevice. Thus only simple calls are required to execute many complicatedprocesses. The complicated processes of retrieving encrypted contentstored in memory locations of card 13, and then subsequently decryptingand formatting the content are handled by SW 100.

Performing accesses to the authentication area of the SD Memory Cardrequires using secret device keys that OEMs must license from the 4CEntity, as mentioned previously. Protecting these key values andrestricting their exposure within SDK SW 100 software layers is one ofthe central considerations in the software design. Isolation of thesekeys (and other resultant values such as session keys) within a singleinternal module while enabling a secure media such as the SD memory carddevice driver to perform operations dependent on these values isachieved in a robust and secure interface methodology. Once again, theSD memory card is used to illustrate the invention; however, theinvention can be used on any secure media such as CDs or other securememory that may be in a card or even in a remotely located storagedevice.

FIG. 8B illustrates the layered structure of SW 100 in more detail.Audio interface 105, video interface 110, and imaging interface 115 arethe points of communication to the device. These interfaces provide asingle point of communication for the device and generally receivesimple commands from the device so that the device does not have to getinvolved with the intricacies of getting encrypted data from a securemedia, then decrypting and processing the data. All of these complexprocesses are handled by SW 100. Interfaces 105, 110, and 115 alsomanage the arrangement of playback such as managing playlists and thecorrelation of images such as that of an artist with the songs of theartist or the various playlists. Application programming interface (API)130A resides within command dispatcher (CD) 130. CD 130 and API 130Areceive commands from interfaces 105, 110, and 115, relay information tothe interfaces, and organize all of the processes that take place in theSW 100—the processes of device 15 related to the playback and recordingof content stored on the secure media, with all of the requisiteencryption, decryption, and compression algorithms.

SD audio engine (SDAE) 140, SD video engine (SDVE) 150, and SD imageengine (SDIE) 160 respectively process audio, video, and image contentresiding on the secure media, upon receipt of instructions from CD 130.This means SDAE 140 can process any of the well known formats for audio,such as AAC, WMA, and MP3. Likewise, SDVE 150 can process any of thewell known formats for video clips such as Windows media files or realnetworks files MPEGs or any other well known type of video files.Finally, SDIE 160 can process any well known type of image files such asTIF, GIF, JPEG, bitmaps, etc. Each interface has a secure API (SAPI) anda non-secure API (NSAPI). The content processed may or may not beencrypted. Encrypted content is accessed through SAPIs 140A, 150A, and160A. These SAPIs communicate with SanDisk security manager (SSM) 180.All commands having to do with secure content are channeled through SSM180. Secure digital security engine (SDSE) 175, which will be describedlater in further detail, handles all encryption and decryptionprocesses. Keys used to authenticate the media and decrypt the contentare contained within and handled exclusively by SDSE 175. Unencryptedcontent residing on the card is accessed through NSAPI 140B, 150B, and160B. These NSAPIs communicate with a non-secure file interface (NSFI)170 in order to access unencrypted content on the media.

In order to read or write data in the storage media, NSFI 170 and SDSE175 communicate with device driver 190. Device driver 190 in the exampleof the SD card manages and drives signals to and from the deviceinterface 39's contacts of the SD card 13. Device driver 190 will betailored to the specific type of device interface 39 of various devicesor media. In the case of a memory card device, driver 190 manages anddrives signals to and from contacts located on device 15. In the case ofoptical media, device driver 190 may manage and drive signals fromvarious hardware components including an optical pick-up unit.Alternatively, in the case of a hard disk drive (hdd), device driver 190will manage and drive the required hdd signals. Device driver 190contains a secure device driver interface (SDDI) 190A, and a non-securedevice driver interface (NSDDI) 190B. SDDI 190A and NSDDI 190B areisolated from each other within device driver 190. SDDI 190Acommunicates exclusively with SDSE 175, while NSDDI 190B communicatesexclusively with NSFI 170.

Device keys and other values central to the SD-Audio security scheme arehoused within one restricted security software module, SD securityengine (SDSE) 175. All manipulation of these values is solely restrictedto this module. Values are never passed in or out to software layersabove SDSE 175. All requests for the security services involving thesekeys are controlled and monitored by SSM 180 that shields this securitymodule. Beneath the security module, the SD Memory Card device driver190 carries out security accesses. Requests for these driver servicesare made via a private driver security interface, secure device driverinterface (SDDI) 190A, that is only known to the security module. SDSE175 uses this interface 190A to perform special security commands suchas Get Media Key Block (MKB). Non-secure device driver interface (NSDDI)190B also utilizes device driver 190 to access any unencrypted files inuser area 41 of card 13.

The security of SW100 architecture resides in the security of its keys.Secret “soft keys” are not stored in temporary secure areas for a longperiod of time, since this increases the possibility of compromising thekeys and thus the encrypted content. SW 100 utilizes a scheme withinSDSE 175 of dynamically generating the needed keys (or “soft keys”) anddeleting them when there is no immediate need for those specific keys.

Operation of SW 100 is now described in more detail. SW 100, inparticular, command dispatcher 130/API 130A have a number of APIroutines that can be called upon to perform a certain function. Althoughthere are many routines, only 22 of the routines are accessed externallyby device 15. These routines are accessed by calls, which are alsoreferred to as commands. In order to retrieve the content in memory card(or other media) 13, the device need only send one of the 22 calls andthe content will be retrieved, decrypted if necessary, and decoded. Inthe case of audio, for example, the device need only send the “play”call, and the music will start.

The following listed APIs allow applications to interface to devicecompliant with the Secure Digital (SD) standard. Although implementationof the invention is illustrated with the SD standard, the presentinvention can be used with many different standards.

TABLE 1 API Routines/Calls Call name/API routine (as seen in appendedFunction of call/API routine source code) 1. Initialize audio systemSdInitAudioSystem 2. Mount media (if necessary) SdMountAudio 3. Unmountaudio (if necessary) SdUnMountAudio 4. Check the free space availableSdDriveFreeSpace 5. Eject media SdEjectCard 6. Get number of playlistsSdGetPlayListCount 7. Get playlists SdGetPlayLists 8. Get the tracktitle (x) SdGetTrackTitle 9. Get the track information SdGetTrackInfo10. Open the track SdOpenTrack 11. Play the track SdPlayTrack 12. Go tothe next track SdNextTrack 13. Stop playback SdStopPlay 14. Pauseplayback SdPauseTrack 15. Resume playback SdResumeTrack 16. Resetplaylist SdResetPlayList 17. Fast forward/rewind playback (+/−)SdForward 18. Add track index to playlist SdAddTKItoPLM 19. Delete trackindex from playlist SdDelTKItoPLM 20. Delete track index from trackSdDelTKItoTMG manager 21. Covert MP3 to internal playbackSdConvertMP3ToSA1 format 22. Convert AAC to internal playbackSdConvertAACToSA1 format

The principle API routines which can be called by device 15 will now bedescribed in detail. Reference will be made to FIGS. 8A-8E.

As can be seen in FIG. 8C, there is a pre-play process 805 and a playprocess 810. The blocks of FIG. 8E are created during the processes ofFIG. 8C. The related API modules are executed when called upon by theuser interface of device 15. In the case of audio playback, calls to themodules are sent by the user interface of device 15 to the audiointerface 105 as seen in FIG. 8B. The primary calls/modules that carryout the functionality listed in the flowchart are indicated on theright. Many of these modules execute other internally and externallyaccessed modules, and the list is not meant to be exhaustive, but ismeant to be a reference to the software code on compact disc that waspreviously incorporated by reference and forms a part of thisapplication. For further detail please refer to the software code.

The device is first powered up in step 803, after which the pre-playprocess 805 commences. The pre-play process has two major phases: apower up initialization phase 805.10, and an audio contentinitialization phase 805.20. Audio content initialization phase will bedescribed in further detail with regard to FIG. 8D.

Generally speaking, in pre-play process 805 the device and media areinitialized and certain information from the media is read from themedia and stored in a buffer of a RAM memory of device 15. As seenpreviously in FIG. 2 this RAM memory may either be system memory 27, RAMmemory 31A of DSP 31, or RAM memory 25A of MCU 25. In step 805A SW 100will get the drive number of the media. In some applications there maybe more than one memory card or disk being accessed by device 15. Inthis step it will get all the drive numbers in order that content oneach of the drives can be properly accessed. This is accomplished withAPI routine SdInitAudioSystem, and can either be called upon by device15 or can be internally called by SW 100 as part of a pre-play routine.SW 100 will then initialize SSM 180 and SDSE 175 within SW 100. This isnecessary before any encrypted keys and content from the media can beprocessed. SW 100 will also initialize the playlist and track manager incard 13.

In step 805B, SW 100 will initialize and verify the media. In the caseof the SD card illustrated here, the MKB process of FIGS. 5-7 will beperformed. This MKB process can also be executed during step 805A, andif previously executed it will not be executed again in step 805B. Forfurther detail of this process please see FIGS. 5-7 and the 4C documentsincorporated earlier. This process will also be discussed in greaterdetail with regard to FIG. 10. In step 805B, media information valueswill be copied from the card 13 and stored in locations of mediainformation block 850 of FIG. 8E in a RAM memory of device 13. This isaccomplished with API routine SdMountAudio, and can either be calledupon by device 15 or can be internally called by SW 100 as part of apre-play routine. Thus values for playlist general information(pTGInfo), the validity number of the media (SanDisk), the drive number(drivenum), the security system of the media (security) and the mountingstatus of the media (mounted) will be filled in their respectivelocations. These locations can then be subsequently read from the RAM ofdevice 15 when called upon by any number of API calls without having toread them from card 13.

After the power-up initialization 805.10 is completed, audio contentinitialization 805.20 commences. Generally speaking, during audiocontent initialization 805.20, information specifying location andsequencing of the encrypted audio content of an individual track andmultiple audio tracks (playlists) are copied from the card (or othermedia) 13 into a small buffer in a RAM of device 15. This information,shown in blocks in FIG. 8E, is thus quickly and easily accessible withinthe device and does not need to be constantly read from or updated tocard 13 during the subsequent play process 810.

Referring to FIG. 8D, the audio content initialization phase 805.20 willbe described in more detail. This phase creates a number of structuresthat act as a local roadmap or directory to the encrypted content onmemory card (or other media) 13.

In step 805C, device 15 calls API module SdGetPlayListCount. This call,and all of the following calls, are generally sent from the software ofa user interface of device 15 to one of the interface modules of SW100.In this illustration of audio playback the call is sent from the userinterface to audio interface 105. In the case of video playback, thecall would be sent to video interface 110 and in the case of imagereproduction, the call would be sent to imaging interface 115. The callis then relayed to command dispatcher 130 which contains the API moduleswithin API 130A.

In step 805D, SdGetPlayListCount will fill in the values for thePlaylist Info block 860 by copying the information from card 13 into aRAM memory of device 15. It will select the appropriate authorizeddrive(s) by referring to media info block 850. The total number ofplaylists for all authorized drives will be copied into a RAM of device15.

In step 805E, device 15 calls API module SdGetPlaylist.

In step 805F, SdGetPlaylist will fill in the values for the playlistinfo block 860 by copying the information from card 13 into a RAM memoryof device 15. It will select the appropriate authorized drive where theplaylist info resides by referring to media info block 850. The totalplayback time of the selected or default playlist in milliseconds(pListTime), the number of tracks in the playlist (tracksInPlist), theindex number corresponding to the current playlist (index), the playlistname string length (Length), and the playlist name (pListName) will befilled into their respective locations of Playlist Info block 860.

In step 805G device 15 calls API module SdGetTrackInfo.

In step 805H, SdGetTrackInfo will fill in the values for the trackinformation block 870 by copying the information from card 13 into a RAMof device 15. It will select the appropriate authorized drive where theplaylist info resides by referring to media info block 850. It willselect the tracks within each playlist by referring to the Playlist infoblock 860. The total track time (trackTime) in milli-seconds includingthe related track units (“TKI's”) in the track, the total track size inbytes (bytesize), including the related TKI's, the number of TKI's inthe track (tkisInTrack), the track number (tracknum), the indexcorresponding the current track (index), and the track information fromthe media (trkInformation) will be filled into their respectivelocations.

In step 805I device 15 calls API module SdOpenTrack.

In step 805J, SdOpenTrack fills in some of the values for the Track GenInfo block 880 by copying the information from card 13 into a RAM ofdevice 15. It will select the appropriate drive by referring to mediainfo block 850, and it will select the tracks within the appropriateplaylists and tracks by referring to Playlist Info block 860 and TrackInfo block 870, the total playback time of the playlist in milliseconds(pListTime), the current playlist number (plistnum), the track number tobe played (tracknum), the first AOB block for the track (firstAOB), andthe current AOB being decrypted (currentAOB).

In step 805K SdOpenTrack fills Track Index Info block 875 by copying theinformation from card 13 into a RAM of device 15. It will select theauthorized drive where the playlist info resides by referring to mediainfo block 850 and playlist info block 860, and it will select theproper tracks within the proper playlists by referring to Playlist infoblock 860 and Track Info block 870.

After Track info block 870 is created, in step 805L, SdOpenTrack willfill in the remaining values of Track General Info Block 880 by copyingthe information from card 13 into a RAM of device 15. The followingvalues will be filled into their respective locations of block 880: averification number for the media (SanDisk), an operation command (CMD),the audio format such as MP3, AAC, or WMA (audioformat), the codecsampling frequency (sampfreq), the application attribute, e.g., music,book image, etc. (appAtrib), the size of the audio object in bytes (sizeAOB), the last AOB block for the track(lastAOB), the total number ofAOB's for the track (countAOB), the current position of sync position inAOB (syncword) also known as the header, the seek position within theAOB(seekposAOB), the elapsed time of the track in milliseconds(trkElapsedTime), the total play time of the track in milliseconds(trkTotalTime), the total track size in bytes including related TKI's(bytesize), the playtime of each element in milliseconds(elementplaytime), the forward seek time (fwTime), the time to the nexttrack (fwNext), the number of the tracks in the playlist(tracksInPlist), the size of the current element (elementsize), theoffset within the current element (element offset), the current elementsin the AOB (currentelement), the total number of elements n the AOB(totalelements), and the file handle of the AOB (fdAOB). In a differentembodiment of the invention, step 805J will completely fill the valuesof Track General Info block 880 and step 805K will be eliminated. TrackIndex Info block 875 is a subset of Track Gen Info block 880 and isdesigned to save space and processing time. It is meant to be referredto by the user interface of device 15 in the event that it is justbrowsing the information. Once the user interface has selected aparticular track for playback, Track Gen info block 880 will be filled,including the subset of information contained in block 875.

SdOpenTrack and can either be called upon by device 15 or can beinternally called by SW 100 as part of a pre-play routine.

Having the blocks and the information of the blocks contained in amemory of the device is an advantage because if there is any failure inthe playback process, it is not necessary to reset the media, i.e.,perform steps 805A or 805B of power up initialization 805.10. Also, itshould normally not be necessary to read the information needed forplayback from card 13. The information in the blocks can be used toaccess the next content (audio, video etc.) frame because theinformation in the blocks 850, 860, 870, 875, and 880 is used as apointer to the content contained in the next frame. The blocks of FIG.8E detail the location within memory card 13 of the files, elements andframes that make up and audio or video track are located within memorycard 13, as was earlier described with regard to FIG. 3C.

The pre-play process of step 805 can be triggered by a number of calls(the numbers in parenthesis indicate the call in Table 1). As seen inFIG. 8C, the external calls that will trigger audio contentinitialization 805.20 are: SdOpenTrack, SdGetPlaylistCount,SdGetPlaylist, and SdGetTrackInfo. SdOpenTrack (10) is internally calledby SdNextTrack (12), SdStopPlay (13), and SdResetPlaylist (16). APImodules SdGetPlaylistCount, SdGetPlaylist, and SdGetTrackInfo can alsobe called internally by SdOpenTrack. Generally, it will be called uponby device 15 for such device functions as displaying the track time,rewinding, fast forwarding, changing playlists, changing graphic userinterface displays, or deleting tracks. Once the pre-play process 805 iscomplete, the play process 810 can commence.

In play process 810, calls that will initiate, stop, or pause playbackof one or more audio or video tracks are received by the audio interface105, video interface 110, or imaging interface 115 of FIG. 8B in step810A. These calls can be seen in FIG. 8C next to play process 810 andare SdPlayTrack, SdNextTrack, SdStopPlay, SdPauseTrack, SdResumeTrack,SdResetPlayList, SdForward, SdAddTKItoPLM, SdDelTKItoPLM, SdDelTKItoTMG,SdConvertMP3ToSA1, and SdConvertAACToSA1.

Regardless of how many API modules are executed, either internally orwhen called upon by the device, two primary modules will always berequired in order to play an audio track. These modules are SdOpenTrack(10) and SdPlayTrack (11). SdOpenTrack (10) and SdPlayTrack (11) willread the information in Track General Info block 880 in order to accessthe encrypted content in the memory locations of clusters of memory card13.

SdOpenTrack (10) is internally called by SdNextTrack (12), SdStopPlay(13), and SdResetPlaylist (16). Generally, it will be called upon bydevice 15 for such device functions as displaying the track time,rewinding, fast forwarding, changing playlists, changing graphic userinterface displays, or deleting tracks.

SdPlayTrack (11) is the core API that plays the music or video track. Itis generally used by a device when the user wants to play the currenttrack, the next track, or when he wants to rewind or fast forward withina track. It is called upon by other API's such as SdNextTrack (12)SdResumeTrack (15) and SdForward (17). SdPlayTrack finds the AOB for theselected track, checks the audio format (MP3, AAC, or WMA etc.) anddecodes the track.

Referring to FIGS. 8B, 9, and 10, playback of an encrypted track, step810B of FIG. 8C, will now be described.

If encrypted content is desired, then commands are issued to/from device15 and SW 100 which require the OEM's 4C-licensed device keys to beused. All processing of these keys is solely limited to the SDSE 175module which is housed beneath the SSM 180. If non secure ornon-encrypted content is requested, NSFI 170 and NSAPI's 140B, 150B, and160B and NSDD 190B will access the content.

When SSM 180 receives a request for security services, it carries it outby passing the command request packet to the process_security functionwithin SDSE 175. Key values are never contained within the requestpackets or exposed at software layers above SDSE 175.

When needed internally by SDSE 175, device keys are retrieved via afunction call into an OEM-supplied library. The library of SDSE 175,security.lib, contains the following APIs designed to reduce the timethat a decrypted key resides in the secure area of the system:

-   1) SEC_AKE API;-   2) SEC_ENC_TKEY API;-   3) SEC_DEC_TKEY API;-   4) SEC_GETCCI API;-   5) SEC_UPDATECCI API.

The functionality and the structure of SW 100 are described in the textof this application and more specifically, the functionality of APIs 1-5above are shown within the flowchart of FIG. 9. The APIs are shown nextto the corresponding functions that they implement. Further detail ofthe implementation of these APIs, as well as all of SW 100, can be seenin the source code that is submitted in an appendix of this application.

Once obtained, the device key is combined with the Media Key Block (MKB)from the SD Memory Card to form the “media key.” This value is keptwithin SDSE 175 for use in processing subsequent requests. Note,however, the “unique media key” (Kmu) is never retained inside SDSE 175.This value, which forms the basis for all security accesses, is alwayscalculated on a real-time basis (and never cached) as an extra securityprecaution. Detailed description of the processing of the keys withinSDSE 175 follows.

The encryption process is in general terms designed to stop unauthorizedcopying of the content located on the secure media. There are manyaspects of the invention that achieve this. First, an entire file, forexample, a song, is never decrypted at once and stored into memory whereit may be vulnerable. The portable device allocates a buffer and SDSE175 reads chunks of encrypted content at a time, decrypts it, and thenwrites over the same buffer over and over again until the end of thefile.

As was seen in FIGS. 6 and 7, the media unique key (Kmu) and title key(Kt) are the keys finally used to decrypt the content. There are manyways to protect the title key. One is to store the keys in a very securearea of device 15, another is to read the title key from the protectedarea 47 of card 13 each time the encrypted buffer is read and decrypted.FIG. 9 is a flow chart depicting the preferred method.

Returning to FIG. 9, in step 205, an MKB image, which, as seen in FIG.4, is 64 kilobytes, is read to process the media key (Km), as seen inFIG. 6, to yield the media unique key (Kmu). This step is furtherdetailed in FIG. 10 which will be described later. After mutualauthentication of the device and the media is complete in step 205, theAKE process is undergone to yield a session key (Ks) that can only beused during that session (as long as the device is turned on or is in anactive state) in step 210. The AKE process can be seen by referring onceagain to FIG. 6. In step 213, the media unique key (Kmu) is deleted. Instep 215, the session key (Ks) is used to decrypt the doubly encryptedtitle key E(E(Kt)) stored in protected area 47 of memory card 13. Theresult is a singly encrypted title key (E(Kt)). In step 220, thisencrypted title key (E(Kt)) is stored in a memory of the device 15. The(E(Kt)) may be stored in system memory 27, RAM memory 25A of MCU 25, orRAM memory 31A of DSP 31. The title key Kt is specific for each title,referred to as a track in the realm of audio and on FIG. 9 used toillustrate the invention. Each track may be made of multiple files, forexample, in the case of a long classical song. For large video clips, atitle may comprise many files. Thus, for all subsequent reading anddecryption of the encrypted content of the track, the title key need notbe retrieved from the memory card because it is stored in a localmemory, and precious time and computing resources can be saved, while atthe same time, the title key remains encrypted for security purposes.

In step 225, a portion of the track is played back. This portion may bein any of the files that comprise the track. In step 225 a, the mediaunique key (Kmu) is calculated once again. In step 225 b, the encryptedtitle key stored in local memory is decrypted. Then, in step 225 c, thetitle key is used to decrypt the content from the buffer of device 15containing content from the user area 41 of card memory card 13.Immediately after the buffer is decrypted, the title key is deleted instep 225 d and the media unique key is deleted in step 225 e. The orderof steps 225 d and 225 e is not important, but it is important that bothkeys are only exposed for the time it takes to read a portion of thetrack. This portion may be anywhere from a fraction of a second ofplayback (decrypted, decompressed, and decoded) content, audio orotherwise, to about ten seconds. Preferably it is two seconds. The timeit takes to read the portion is dependent on many factors including theprocessing speed and the buffer size of the device. As discussedpreviously, SW 100 can be executed by either the MCU 25 or DSP 31 andstored in any of the memory 27, 25A, 31A or 32 of device 15, thus, theprocessing times can vary. This is repeated until all portions of thetrack are read as seen in step 230. Once all portions have been read thesystem can move on to the next track, as shown in step 235, if playbackis to continue. This may be the case, for example, if the user haschosen to play an entire playlist.

When the all portions of track have been read and the reading of thenext track is to commence, the process will begin again at step 215 andwill retrieve the next doubly encrypted title key from the protectedarea 47 of card 13. This is generally the case if the user has set thedevice in motion to play an entire playlist that includes multipletracks. If the session is closed (i.e., device 15 has been turned on oroff), then a new session key will have to be generated and the processwill initiate at step 210. If memory card is removed or freshlyinserted, the device and media will have to be re-authenticated and theprocess will begin again at step 205 in order to read a track.

FIG. 10 describes the operation of processing the Media Key Block, step205 of FIG. 9 described above. As was seen in FIG. 4, an MKB image 49 is64 Kbytes in length. Reading the entire image 49 at once to calculatethe MKB would be inefficient, requiring a large RAM and long processingtimes. The present system reduces RAM requirements and decreasesprocessing time. The MKB image 49 is divided into chunks 1 through 128.Each chunk is 512 bytes and may contain one of four different types ofrecords of the MKB: the verify media key record (VMKR) known as 0×81;the calculate media key record (CMKR) known as 0×01; the conditionallycalculate media key record (CCMKR) known as 0×82; or the end media keyrecord (EMKR) known as 0×02. These records are described in the ContentProtection for Recordable Media (CPRM) Specification of the 4C Entity,referenced above.

In this example, the chunk length and the buffer length are the same.However, the buffer length and chunk length can both range from 256bytes to 4096 bytes. Each record is examined to perform specificoperations based on the record type and certain data will be saved forlater to obtain the Media Key. The record length is added to the totallength of the buffer offset every time a record is identified. The chunknumber is calculated by dividing the total length with the chunk length.The chunk number is the index to the Media Key Block of a selected chunkdata. The remainder of the total length is the offset to the selectedchunk data. The row and column are used to figure out where theencrypted media key and the conditional encrypted media key are. Thoseencrypted keys are saved and the decryption C2 cipher in ElectronicCodebook Mode algorithm is performed to obtain the Media Key. This MediaKey is then verified for a correct final Media Key (Km).

The number of reads, T, required per MKB chunk for obtaining the MediaKey (Km) from the MKB associated with the number of records is shownbelow:

Number of Records <T<(Number of records*2)

-   -   T: Number of times required for accessing MKB chunks

Each record has different length and data values. The information ofeach record can be obtained within two reads. Since there are fourrecords, between 4 and 8 reads will be necessary to process the MKBchunk and obtain the records.

-   -   Therefore, the number of reads, T, are:

4<T<8

Suppose that it takes N ms to access 512-byte of MKB data. It will take(128*N)ms to access an entire 64K MKB image to obtain the Media Key fromthe first method. It only takes, from the second method, (8*N)ms, as theworst case scenario, to obtain the Media Key. Thus, there is aconsiderable time saved using this scheme. On the average, to obtain theMedia Key (Km), the number of reads would be in the range of 4 to 6, andthe time necessary would be proportionately less than shown above.

Step 205 of FIG. 9, expanded here in FIG. 10, is performed until a finalmedia key is produced in step 205.75 or the media is rejected in step205.80. Not all of the 128 chunks need to be read, and not all of the512 bytes per chunk need to be read in order to calculate the media key.Processing MKB data is an operation that requires requesting a chunk ofdata at a time, pointing to the desired location within that specificchunk and computing the obtained values. Not all MKB data is needed. Thealgorithm depicted in FIG. 10 will provide a mathematical calculation tofigure out exactly what chunk of MKB data is needed, what record shouldbe processed and where the encrypted data is located.

In step 205.5, the buffer pointer is set to the data buffer and thebuffer offset is cleared. Next, in step 205.10, the chunk number ischecked to see if it is equal to or larger than the maximum chunknumber. If it is, an error will be returned in step 205.15. If it isnot, the chunk number will be incremented and new data will be loadedinto the buffer in step 205.20. Then the buffer offset will be updatedin step 205.25. Thus, the pointer can be set to the correct location(the chunk number plus offset). In step 205.30, the buffer pointer isset to the buffer offset. In step 205.40 the buffer is read starting atthe offset where the pointer is located. The system will then determinewhat type of record it is reading. As seen in step 205.40, the systemwill first check what type of record is being read, and what recordlength is associated with that record. The actions that will followdiffer depending upon the record type and length. The record length ofeach record will be used to determine where the buffer pointer should belocated in reading the subsequent record. This is reflected by steps205.49, updating the buffer offset and setting the buffer pointer at thenew offset.

If the record is a CMKR as shown in step 205.42, then the system updatesthe buffer chunk number and offset to the correct MKB location where theencrypted media key (Km)is located in step 205.49. Each card has 16MKBs. Thus, the system will get the offset where the encrypted media keyis, go to the specific MKB chunk number, allocate buffer (16 blocks×512bytes), and go to the offset within each block to read the encryptedmedia key. Then the system uses a device key (Kd) supplied from device15 to decrypt (calculate) the media key in step 205.50. Once the mediakey has been calculated the next step is to verify the media key.

If the record is a VMKR as evaluated in step 205.44, the media key thatwas previously calculated, either on the first attempt in step 205.50,or in a subsequent attempt in step 205.65, will be compared to areference media key (Km) in step 205.55. In order to do this, referencemedia key will first be stored locally. If the key is the same a passwill be returned, which in hex is DEADBEEF, and the system will not needto conditionally calculate the media key. In order to figure out whereto start reading the next record, the record length of the VMKR is usedto move the buffer pointer to the next record. If it is not the same itthen it will be calculated again when a CCMKR record is read in step205.46. When this record is read, the media key will be calculated onceagain in step 205.65 after the buffer point has been set to read at theupdated buffer offset in step 205.49, and then it will be subsequentlyverified when the next VMKR is read. The maximum number of times theCCMKR is calculated may be set by the system and preferably one.

The first calculation takes place when a CMKR is found. If it issuccessfully calculated, as determined during the verification processinitiated when a VMKR is found, then there will be no need toconditionally calculate the media key (Km). If the verification isunsuccessful then when a CCMKR is found the media key (Km) will berecalculated and re-verified. This means that there are two chances tocalculate the media key. Finally, if the record is an EMKR as evaluatedin step 205.48, then in step 205.75 the system will verify that at theend of the record a valid media key (Km) is present, and in step 205.75the final media key (Km) will be produced, after the buffer pointer isset at a the proper offset for this type of record in step 205.49. If,however, a valid media key is not returned in step 205.70, the mediawill be rejected in step 205.80. If the final media key is returned instep 205.70, the processing will continue at step 210 of FIG. 9, asshown by step 205.85. Thus the MKB process is complete.

Functions within SDSE 175 perform security accesses such as Get MKB byusing a secure device driver interface (SDDI) 190A to device driver 190.This same device driver, SDDI 190A also makes use of functions withinSDSE 175 which it can call directly. For example, prior to issuing aread of the authentication area, SDDI 190 a must first call the sec_akefunction within SDSE 175. The sec_ake function will in turn call backinto SDDI 190A. This “dual calling relationship” which facilitates theisolation of the device key within SDSE 175 is unique to SW 100 simplementation of the SD-Audio standards.

Since SDSE 175 handles all key-oriented processing, and these values areneeded when certain SD commands are received by the audio interface 105,video interface 110, or image interface 115, the device driver must makeuse of functions within SDSE 175 which it can call directly. Whencarrying out the functions, SDSE module 175 must in turn call back intothe device driver 190's private security interface, SDDI 190A. This“dual calling relationship” allows interwoven requests between SDSE 175and device driver 190, thus enabling key values to be isolated withinthe security module.

The SDSE 175 software layer invokes security device driver services viathe private interface by initiating a security driver request packet andcalling the security driver interface entry point passing a requestpacket pointer.

In order to clarify the appended source code which has been incorporatedby reference, the following tables are provided.

The request packet (defined in sdapi.h) consists of a data type SSMSERVEwhich is defined as follows:

TABLE 2 Variable Variable name Typedef struct _mySecuredDrv { Databuffer UCHAR *buffer Number of data blocks UINT16 noBlocks Applicationunique Number UINT16 mkb_ID Start address UINT16 lba Security flag INT16securityFlag Drive number INT16 driveNo Command index INT16 opCode }

Command index (INT16 opCode) holds the command for the service beingrequested. Supported commands include:

TABLE 3 Command Functional Code Routine Device identify #defineSDDRV_IDENT 0 Security identify #define SDDRV_SECIDENT 1 Secure read#define SDDRV_SECRD 2 Secure write #define SDDRV_SECWR 3 Secure erase#define SDDRV_SECERASE 4 Read MKB #define SDDRV_RDMKB 5 Get MID #defineSDDRV_GETMID 6 Set challenge #define SDDRV_SETCHALGE 7 Get challenge#define SDDRV_GETCHALGE 8 Set response #define SDDRV_SETRESP 9 Getresponse #define SDDRV_GETRESP 10 Change size of protected area #defineSDDRV_CHANGESA 11

Security device driver service requests are issued from the SDSE175module. For example, the Generate Challenge 1 function sendschallenge 1 as follows:

TABLE 4 Generate Challenge 1 Command Operation Call security routineSDSECURITYDRV mySecDrv Set drive number mySecDrv.driveNo = (INT16)drvSet memory address within media mySecDrv.lba = 0 Number of data blocksmySecDrv.noBlocks = 1 Set challenge mySecDrv.opCode = SDDRV_SETCHALGESend challenge 1 mySecDrv.buffer = Chlg1 Call to device driverscDDHandler(&mySecDrv)

Because all key manipulation is confined to SDSE 175, SSDI 190A mustrely on SDSE 175 functions to perform Authentication Key Exchange (AKE)or for decrypting data that has been transferred across the bus (notethat all data sent across the bus is first encrypted using the “sessionkey” which is generated from each AKE.)

When performing the AKE, SDSE 175 must send commands to the SD MemoryCard 13, thus, it must in turn call into SDDI 190A. This callingrelationship is outlined in the diagram of FIG. 7 which depicts thesteps necessary to process a read of the authentication area.

Notice that the sec_ake function within the SDSE 175, when called by thesecurity SDDI 190A, performs four calls back into the security devicedriver via the private driver interface. These four requests consist of:SDDRV_SETCHALGE, SDDRV_GETCHALGE, SDDRV_SETRESP, and SDDRV_GETRESP. Thisenables the security module to carry out the requisite set challenge/getchallenge, set response/get response steps seen in FIG. 7. The resultantsession key is stored within the security module. This is used todecrypt data when the security device driver calls into the SDSE 175'sbus_decrypt function to get information from SDDI 190A.

The system and method of the present invention are advantageous overprior techniques in many ways. The present invention provides a turnkeysolution for original equipment manufacturers to access encryptedcontent without having to have any knowledge of the memory structure ofthe storage media. The decryption process by itself is very complex.Furthermore, simply reading and writing to a memory card or compact diskis complex in and of itself. All a manufacturer needs to do is send asimple command such as “play” or “next track” and return the decryptedcontent from whatever the memory device happens to be.

Device keys and resultant session keys are manipulated in a veryisolated and protected software layer. These are never exposed in upperlayers. Even the lower device driver layer is not given direct access tothe keys. Device keys are retrieved from an OEM-supplied library whengenerating the media key. This key is retained within the securityengine, but the media unique key (Kmu) which is the heart of thesecurity scheme is never stored. A private interface to the securityengine enables the security engine to gain low-level access to thememory card while keeping the exposure of all security-related keys(e.g., device keys, media keys, session keys) confined within thesecurity engine. A “dual calling relationship” allows the securityengine and the security device driver to make interwoven use of eachother's services.

While particular embodiments of the present invention and theiradvantages have been shown and described, it should be understood thatvarious changes, substitutions, and alterations can be made thereinwithout departing from the spirit and scope of the invention as definedby the appended claims. For example, although usage of an SD memory cardhas been shown to illustrate the functioning of the invention, theinvention can be used on any media having encrypted content. It can alsobe utilized by any type of device. Furthermore, encrypted content can bedecrypted from any type of memory device, whether it be fixed orremovable, and whether it be solid state or rotating. The content is notlimited to audio or video, but can be any content worthy of encryption.

1. A method of securing a storage device and providing content to anauthorized entity yet protecting the content from unauthorizedduplication: providing a flash memory array within the storage device;providing a freely accessible read/write area within the memory array,the freely accessible read/write area being a first distinct area;providing a read/write area within the memory array that is accessibleonly after a successful mutual authentication between a host device andthe storage device comprising the flash memory array has occurred, theread/write area within the memory array that is accessible only after asuccessful mutual authentication being a second distinct area within thememory array; providing a write protected area within the memory arraythat is accessible only by the storage device itself, the writeprotected area being a third distinct area within the memory array;providing a write protected area that is accessible for reading fromoutside of the storage device, the write protected area being a fourthdistinct area within the memory array; and storing the content in anencrypted format in the freely accessible read/write area.
 2. The methodof claim 1, further comprising storing a media unique key in the writeprotected area within the memory array that is accessible only by thestorage device itself.
 3. The method of claim 2, further comprisingstoring title keys necessary to access content in the freely accessibleread/write area within the write protected area within the memory arraythat is accessible only by the storage device itself.
 4. The method ofclaim 3, further comprising: providing copy control information withinthe read/write area within the memory array that is accessible onlyafter a successful mutual authentication; and concatenating andencrypting the title keys and the copy control information together withthe media unique key stored in the write protected area within thememory array that is accessible only by the storage device itself. 5.The method of claim 1, further comprising storing a media identifierunique to each storage device within the write protected area that isaccessible for reading from outside of the storage device.
 6. The methodof claim 5, further comprising storing media key blocks within the writeprotected area that is accessible for reading from outside of thestorage device.
 7. The method of claim 6, further comprisingtransferring the media key blocks from the write protected area that isaccessible for reading from outside of the storage device to a portabledevice, the portable device having a key able to decrypt the transferredmedia key blocks.
 8. The method of claim 7, further comprisingtransferring a piece of the encrypted content from the freely accessibleread/write area to the portable storage device, the portable storagedevice having an encrypted version of the title key used to encrypt thepiece of the encrypted content.
 9. A system for providing andreproducing content for an authorized entity yet protecting the contentfrom unauthorized duplication, the system comprising: a host device forreproducing the content; a storage device comprising a flash memoryarray; a freely accessible read/write area within the memory array, thefreely accessible read/write area being a first distinct area; aread/write area within the memory array that is accessible only after asuccessful mutual authentication between the host device and the storagedevice has occurred, the read/write area within the memory array that isaccessible only after a successful mutual authentication being a seconddistinct area within the memory array; a write protected area within thememory array that is accessible only by the storage device itself, thewrite protected area being a third distinct area within the memory arrayand having records ; and a write protected area that is accessible forreading from outside of the storage device, the write protected areabeing a fourth distinct area within the memory array, the content beingfreely accessible but only reproducible if the host device cansuccessfully mutually authenticate with the storage device and accessthe second distinct read/write area.